2.1 The Invention and Preferable Features Thereof
According to the present invention there is provided a method and system of authenticating access to computer resource in a mobile device as set out in the pre-characterising portions of the independent claims. An embodiment also may provide a method and system of authentication an application running on a mobile device.
According to a first aspect of the present invention, a method of authenticating a computer resource on a mobile device comprises:                storing an encrypted resource authorization;        transmitting the encrypted authorization to a separate portable security token; on the token, decrypting the encrypted authorization and generating at least partially therefrom an unlock response;        securely transmitting the unlock response to the mobile device;        requiring a user to authenticate separately on the mobile device; and        unlocking the resource if the required unlock response and the separate authentication are both valid.        
In an embodiment, the encrypted resource authorization may be on the device. In an embodiment, the requiring step is omitted, and the unlocking is performed without consideration of separate authentication.
The unlock response may comprise a plain authorization, obtained by decrypting the decrypted authorization
The unlock response may alternatively comprise a function (such as a hash) of a plain authorization, obtained by decrypting the decrypted authorization, and additional information. Thus, in one usage mode, the token may verify and decrypt the encrypted authorization. Then, instead of returning a plain authorization to the device, protected by a session or other encryption key, the token may perform some computation on the plain authorization and possibly some other information (eg token-based information), and return the result to the device. Examples include the following:                Example 1: Digital Signature: computation=digital signature function, plain authorization=private signing key; parameter=hash of message; output=digital signature on message hash        Example 2: Key Derivation: computation=key derivation function; plain authorization=key derivation master secret; parameters=context information, output length; output=key derived from master secret        Example 3: Re-encryption: computation=encryption function; plain authorization=encryption key; parameter=(another) encryption key; output=the plain authorization encrypted with a different key The authorization may comprise a password, PIN or cryptographic key.        
The unlock response may be transmitted to the mobile device under the protection of an encryption key, such as a session key.
The token may store user/token ownership credentials, the decryption on the token being based on the user credentials.
The method provides two-factor (or multi-factor) authentication by requiring a user in addition to authenticate separately on the mobile device, for example by the authentication on the mobile device being validated on the token before the unlock code is sent. Preferably, the method requires a proof of knowledge (eg a PIN) from the device (and ultimately from the user) before decrypting the authorization. The proof may be provided after mutual authentication. Alternatively, the device authentication may be entirely independent of the token authentication.
In an embodiment, the token may operate in single factor mode, which decrypts authorization after mutual authentication with the device.
A service may be run on the mobile device which controls device cryptographic functions and access to the resource. An applet may be run on the token which provides token cryptographic functions.
The user credentials may be generated by the token and never leave the token (or the app running on the token).
Preferably, the encrypted authorization stored on the mobile device can be decrypted solely with the corresponding user credentials stored on the token.
The method may include verifying integrity on the token by a message authentication code (MAC) received from the device.
The method may include verifying the integrity of the encrypted authorization on the token prior to decryption.
The device and the token may perform cryptographic mutual authentication before transmission of the encrypted authorization.
The encryption, decryption and/or the mutual authentication may be provided by symmetric key cryptography
A user secret may be passed from the device to the token and may be validated by the token before the decryption operation takes place.
The resource may comprise data, or an application running or stored on the mobile device.
According to another aspect of the invention there is provided:
a mobile device;
a token including token storage for storing private user credentials, a token communications system, and a token processor providing cryptographic functions;
and wherein in use an encrypted authorization is transmitted by the device communications system to the token; is decrypted on the token using the user credentials; the token generating at least partially therefrom an unlock response, the unlock response being securely transmitted by the token communications system to the mobile device; requiring a user to authenticate separately on the mobile device; and unlocking the resource if the required unlock response and the separate authentication are both valid.
The device communications system and the token communications system may communicate over the air, eg by Near Field Communication (NFC), Bluetooth or BLE. Alternatively, the device communications system and the token communications system may communicate only when the token is in contact with the device via a physical interface.
The device communications system may send a user secret to the token which is validated by the token before the decryption operation takes place.
The device communications system may send a message authentication code (MAC) to the token, which is validated by the token before the decryption operation takes place.
According to a further aspect of the invention, there is provided:
a hardware token for authenticating access to a computer resource via a mobile device, the token comprising:
token storage for the storage of a plurality of user credentials;
a token communications system for communicating with a mobile device;
a token processor providing cryptographic functions; and
wherein, in use:
on receipt by the token communications system of an encrypted authorization, the token processor verifies the integrity and decrypts the encrypted authorization and generates at least partially therefrom an unlock response, and wherein the token communications system securely transmits the unlock response for use by a mobile device.
The preferred system of the present invention preferably comprises:                1. One or more mobile devices        2. An NFC, Bluetooth or BLE token programmed to:                    a) Be able to mutually authenticated with any of the user's devices            b) Respond only the commands issued by any of the user's devices            c) Perform encryption and integrity protection of data provided by the device            d) Return the cryptographically protected data            e) Perform the decryption and integrity verification on previously protected data            f) Optionally require validation of a user PIN prior to performing decryption operations                        3. A password manager application installed each the mobile device        4. Any number of third-party applications secured by the system        
The mobile device may comprise any mobile or portable hardware device which is capable of running user applications and handling communication and cryptographic functions. Typical devices include mobile phones, tablets, laptop computers and the like. The token may be any portable or mobile hardware token which is capable of communication (preferably contactless communication) with a mobile device and which includes storage and an executable system which is capable of handling communications and cryptographic functions.
The protected computer resource may be held in a device memory or store or (where an application) may be held ready for execution or may be actually running in an execution environment. To that end, the device may include a store, a memory, and a processor.
Typically, the token will be a contactless smart card, although other tokens held by or carried on the person would be equally possible. Suitable tokens might include a ring to be worn on the user's finger, a device incorporated into a watch, belt, spectacles, clothing or anything else normally worn by the user, or even a device embedded under the user's skin. The token may have button(s), touch-sensitive area(s) or other means to allow manual or other user feedback/input via the token.
The application authentication stored on the device may comprise an application password or PIN. The user credentials stored on the token may comprise a private cryptographic key.
It is preferred that communication between the token and the mobile device makes use of NFC, although other channels could equally well be used including Bluetooth, Bluetooth Low Energy (BLE), or other types of radio frequency communication. Tokens requiring contact with the mobile device, including swipe cards and electrical contactcards are also envisaged.
According to another aspect of the invention, a system of authenticating access to a computer resource on a mobile device with a portable security token comprises:                a device including a computer resource to be protected, a device communications system, and device storage for storing encrypted resource authorization;        a token including token storage for storing private user credentials, a token communications system, and a token processor providing cryptographic functions;        and wherein in use the encrypted authorization stored on the device is transmitted by the device communications system to the token, is decrypted on the token using the user credentials, the token generating at least partially therefrom an unlock response, the unlock response being securely transmitted by the token communications system to the mobile device, and        the device being arranged to unlock the resource if the received unlock response is valid.        
According to a further aspect of the invention, a hardware token for authenticating a computer resource on a mobile device, the token comprises:                token storage for the storage of a plurality of user credentials;        a token communications system for communicating with a mobile device;        a token processor providing cryptographic functions; and        wherein, in use:                    on receipt by the token communications system of an encrypted authorization, the token processor verifies the integrity and decrypts the encrypted authorization and generates at least partially therefrom an unlock response, and wherein the token communications system securely transmits the unlock response for use by a mobile device.                        
2.2 Hoverkey Level 1
In the preferred embodiment the present invention is preferably embodied within a product called Hoverkey. Hoverkey's design is optimised for ease of integration with existing mobile apps and web apps, as well as ease of use. It implements a secure user credential (e.g. password) storage and retrieval system, secured using NFC tokens.
The present application is particularly concerned with an embodiment that uses a specific security design, referred to in this description as “level 1”. References to Hoverkey level 1 (or Hoverkey L1) should be understood accordingly.
2.2.1 Security Concept
The concept behind Hoverkey L1 is designed to work with all existing applications which authenticate the user using a user name and password combination, although authentication methods other than passwords may be used. Typically, without any changes to the application to be accessed, the technology simply replaces manual entry of the user's password with a touch of an NFC token. This embodiment offers the following advantages:                No changes required for the application server, which allows easy integration        Changes to any existing application clients can be easily implemented through the use of a Hoverkey Component.        Better security by letting technology to “remember” passwords for the user, which means                    The user can choose passwords that are more secure (longer and more “random”)            The user can choose different password for different accounts without the fear or inconvenience of forgotten passwords                        Eliminates the need for entering alphanumeric passwords on an onscreen keyboard, especially when symbols are included, which is slow and error-prone and subject to shoulder-surfing attacks.        
3.1 Deployment Model
At a high level, the preferred Hoverkey deployment model is summarised below:                Each User has one or more NFC-enabled mobile device, which may be provided by company or owned by User.        Each User is issued with a unique NFC security token.        Each NFC token may be paired with all devices belonging to the same User.        
The following steps are taken in deploying a Hoverkey:                Hoverkey purchases blank NFC tokens from resellers        Upon receipt of trial or purchase order, Hoverkey formats NFC tokens for the Customer or a partner issuer        Upon receipt of the NFC token, the User invokes the activation function        The User then configure their Hoverkey-enabled apps with their credentials        
3.2 Architecture
The high level architecture of Hoverkey L1 is illustrated in FIG. 1. Each Developer App (App 1, App 2 and App 3 in the diagram) are embedded with the Hoverkey L1 Component, which allows it to communicate with the Hoverkey Service via an inter-process communication (IPC) protocol.
On each mobile device, there is a single instance of Hoverkey Service which accepts requests from an App and when a password is required. Hoverkey Service retrieves the password on behalf of the App through a series of exchanges with the Java Card applet via the NFC interface.
The advantages of using a service include:                Removes the need share authentication keys (for Applet access) between Apps        No need for Apps to require NFC permissions        Centralised, mediated access to Applet which makes it possible to prevent concurrent access.        
On the Android platform, possible IPC mechanisms include the Intent method for simple, coarse grained integration, or the Remote Service method using Android Interface Definition Language (AIDL) for fine-grained, lower-level integration.
Hoverkey-protected passwords are encrypted by the card Applet at registration and stored on the mobile device within the Hoverkey App. When access is required, the registered App requests the password via the Hoverkey App, which in turns requests the password be decrypted by the Applet.
3.3 Main Security Design Features                Activation and Pairing: A Hoverkey token can only be used with a device with which it has been paired (at activation). Each mobile device many only be paired with one token. Each token may be paired with up to four devices.        Registration: To defend against malicious apps, third-party apps may only use Hoverkey services after a secure on-device registration process. Subsequent password access requires proof of previous registration.        Two-Factor: Each password may additionally protected with a user chosen PIN to provide a form of two-factor authentication. Three or more levels of authentication may optionally be provided.        Cryptographic security: Hoverkey uses industry-standard cryptographic algorithms and modes for protection of user passwords, supported by best practices in secure key management.        Token Security: Hoverkey token are security-managed throughout their lifecycle to ensure the risks are minimized at all stages.        
3.4 Using Hoverkey L1
To use Hoverkey L1, the following steps are followed:                1. New Customer organization orders Hoverkey L1 Cards for their mobile users        2. Hoverkey (or Partner) generates an OrgID for the customer.                    a) Optionally, a RegKey is generated for the customer if they intend to develop their own private Apps, which is delivered the Customer or Developer for embedding into their Apps.                        3. Hoverkey formats the required number of cards with OrgID, MasterAPIKey, Admin Key, User Authentication Key and PUKs, and send them to Customer or Developer.        4. Customer development team embeds Hoverkey Component into their own App(s) and configure them with their OrgID and RegKey during development        5. User installs Customer or Developer App(s) and Hoverkey App (from Google Play Store)        6. User receives (formatted) token from Sys Admin and activation email (containing an activation URL)        7. User activates token from within Hoverkey App and sets a PIN                    a) The Hoverkey App downloads a configuration profile file            b) User is reminded to delete activation email when activation completes                        8. Third-party Apps register themselves with Hoverkey App (typically with a user name and password-once for each Customer or Developer App)        9. User starts to use Hoverkey-enabled mobile Apps        10. User may pair additional devices to the token up to four devices.                    a) If a Hoverkey server is used, App data may be synchronized from the server            b) All Hoverkey-enabled Apps must be re-registered on the new device (as per Step 8).                        